N. D. L. A. : cet article est généré via une commande du type ansible-playbook InternetEstCassé.yml pour tester réellement les commandes.
Internet est cassé. Le Web ne marche plus. Le réseau est pété. Ça marche pas. Ce site est indisponible. Des lutins bloquent ma connexion. Les tuyaux sont bouchés. Y a Firefox qui veut pas, etc. Quand il y a un souci de réseau, toutes sortes d’imprécations, de suppositions, de supplications ou de raisons sont lancées. Peut‐on aller plus loin et essayer d’y voir plus clair, de déboguer un peu le souci et d’identifier le problème.
On va parler un peu d'IP — surtout la version 4 —, de TCP, d’UDP, d’ICMP, d’ARP, de DNS, de HTTP, etc., d’un peu de vue pratique de vérification du bon fonctionnement ou de recherche d’un souci. En dehors des pages Wikipédia, une lecture utile : la RFC 1180 « A TCP/IP Tutorial » (avec une traduction en français disponible).
Sommaire
Tester un flux TCP ou UDP
TL;DR : En TCP on va avoir des réponses de type connexion refusée si le port est fermé ou filtré avec rejet, une attente ou un délai d’attente trop long si le trafic est poubellisé, et une connexion établie si tout va bien. En UDP, on sera notifié d’une erreur en cas de port fermé ou filtré avec rejet, et ne saura pas différencier un port ouvert d’une « poubellisation » du trafic. Il y a plein d’outils possibles pour tester un flux TCP ou UDP en client ou en serveur.
Prenons un cas simple : on sait si l’on utilise du TCP ou de l’UDP, et l’on veut joindre un port précis sur une adresse IP donnée.
Port TCP
Port TCP fermé
Commençons par essayer de joindre un port fermé (rien en écoute, le programme qui devait écouter dessus n’a pas été lancé, a mal démarré, écoute sur une autre adresse ou port, une autre version d’IP, a déjà planté, etc.). Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60001, avec ce que l’on a sous la main (souvent sur un serveur, le choix des outils disponibles est limité). On constate des réponses de type connexion refusée.
$ telnet 127.0.0.1 60001
(durée d'exécution 00:00)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection refused
(code de retour 1)
$ nc -t -v 127.0.0.1 60001
(durée d'exécution 00:00)
nc: connect to 127.0.0.1 port 60001 (tcp) failed: Connection refused
(code de retour 1)
$ bash -c exec 3<>/dev/tcp/127.0.0.1/60001
(durée d'exécution 00:00)
bash: connect: Connexion refusée
bash: /dev/tcp/127.0.0.1/60001: Connexion refusée
(code de retour 1)
$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60001
(durée d'exécution 00:00)
tcp_open:ztcp:174: connection failed: connexion refusée
(code de retour 1)
$ nmap -v -sT -p 60001 127.0.0.1
(durée d'exécution 00:00)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:06 CEST
Initiating Ping Scan at 19:06
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:06, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:06
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:06, 0.00s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
PORT STATE SERVICE
60001/tcp closed unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
(code de retour 0)
$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60001 127.0.0.1 -O info
(durée d'exécution 00:00)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 localhost (127.0.0.1) <rst,ack> 0.033 ms
(code de retour 0)
$ openssl s_client -connect 127.0.0.1:60001
(durée d'exécution 00:00)
140595570463872:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140595570463872:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
(code de retour 1)
$ ssh -p 60001 127.0.0.1
(durée d'exécution 00:00)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60001: Connection refused
(code de retour 255)
$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60001", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
(durée d'exécution 00:00)
ERROR in Socket Creation : Connection refused
(code de retour 111)
$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60001))
(durée d'exécution 00:00)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ConnectionRefusedError: [Errno 111] Connection refused
(code de retour 1)
$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60001)
(durée d'exécution 00:00)
-e:1:in `initialize': Connection refused - connect(2) for "127.0.0.1" port 60001 (Errno::ECONNREFUSED)
from -e:1:in `open'
from -e:1:in `<main>'
(code de retour 1)
$ curl -v -s --max-time 60 http://127.0.0.1:60001
(durée d'exécution 00:00)
* Expire in 0 ms for 6 (transfer 0x55bf2d3fec40)
* Expire in 60000 ms for 8 (transfer 0x55bf2d3fec40)
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55bf2d3fec40)
* connect to 127.0.0.1 port 60001 failed: Connexion refusée
* Failed to connect to 127.0.0.1 port 60001: Connexion refusée
* Closing connection 0
(code de retour 7)
$ wget --timeout=60 --tries=1 http://127.0.0.1:60001
(durée d'exécution 00:00)
--2019-06-30 19:06:05-- http://127.0.0.1:60001/
Connexion à 127.0.0.1:60001… échec : Connexion refusée.
(code de retour 4)
$ links -dump http://127.0.0.1:60001
(durée d'exécution 00:00)
Connection refused
(code de retour 1)
$ chromium http://127.0.0.1:60001
(Ce site est inaccessible. 127.0.0.1 n'autorise pas la connexion. ERR_CONNECTION_REFUSED)
$ firefox http://127.0.0.1:60001
(Unable to connect Firefox can’t establish a connection to the server at 127.0.0.1:60001)
Port TCP filtré avec rejet
Essayons de joindre un port TCP filtré avec rejet par un pare‐feu. Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60000 (et l’on va obtenir exactement le même résultat que précédemment, à part pour nmap).
$ telnet 127.0.0.1 60000
(durée d'exécution 0:00:01.015323)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection refused
(code de retour 1)
$ nc -t -v 127.0.0.1 60000
(durée d'exécution 0:00:01.012197)
nc: connect to 127.0.0.1 port 60000 (tcp) failed: Connection refused
(code de retour 1)
$ bash -c exec 3<>/dev/tcp/127.0.0.1/60000
(durée d'exécution 0:00:01.006805)
bash: connect: Connexion refusée
bash: /dev/tcp/127.0.0.1/60000: Connexion refusée
(code de retour 1)
$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60000
(durée d'exécution 0:00:01.026754)
tcp_open:ztcp:174: connection failed: connexion refusée
(code de retour 1)
$ nmap -v -sT -p 60000 127.0.0.1
(durée d'exécution 0:00:00.277299)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:06 CEST
Initiating Ping Scan at 19:06
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:06, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:06
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:06, 0.20s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).
PORT STATE SERVICE
60000/tcp filtered unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds
(code de retour 0)
$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60000 127.0.0.1 -O info
(durée d'exécution 0:00:00.019657)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 localhost (127.0.0.1) 0.030 ms
(code de retour 0)
$ openssl s_client -connect 127.0.0.1:60000
(durée d'exécution 0:00:01.042588)
140296376857728:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140296376857728:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
(code de retour 1)
$ ssh -p 60000 127.0.0.1
(durée d'exécution 0:00:01.022311)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60000: Connection refused
(code de retour 255)
$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60000", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
(durée d'exécution 0:00:01.052922)
ERROR in Socket Creation : Connection refused
(code de retour 111)
$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60000))
(durée d'exécution 0:00:01.077612)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ConnectionRefusedError: [Errno 111] Connection refused
(code de retour 1)
$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60000)
(durée d'exécution 0:00:01.178000)
-e:1:in `initialize': Connection refused - connect(2) for "127.0.0.1" port 60000 (Errno::ECONNREFUSED)
from -e:1:in `open'
from -e:1:in `<main>'
(code de retour 1)
$ curl -v -s --max-time 60 http://127.0.0.1:60000
(durée d'exécution 0:00:01.038146)
* Expire in 0 ms for 6 (transfer 0x55d959531c40)
* Expire in 60000 ms for 8 (transfer 0x55d959531c40)
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d959531c40)
* connect to 127.0.0.1 port 60000 failed: Connexion refusée
* Failed to connect to 127.0.0.1 port 60000: Connexion refusée
* Closing connection 0
(code de retour 7)
$ wget --timeout=60 --tries=1 http://127.0.0.1:60000
(durée d'exécution 0:00:01.031294)
--2019-06-30 19:06:20-- http://127.0.0.1:60000/
Connexion à 127.0.0.1:60000… échec : Connexion refusée.
(code de retour 4)
$ links -dump http://127.0.0.1:60000
(durée d'exécution 0:00:03.066049)
Connection refused
(code de retour 1)
$ chromium http://127.0.0.1:60000
(Ce site est inaccessible. 127.0.0.1 n'autorise pas la connexion. ERR_CONNECTION_REFUSED)
$ firefox http://127.0.0.1:60000
(Unable to connect Firefox can’t establish a connection to the server at 127.0.0.1:60000)
Port TCP filtré avec poubellisation
Maintenant tentons de joindre un port TCP filtré avec poubellisation des paquets par un pare‐feu. Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60020. Les résultats obtenus sont de type délai d’attente trop long, en l’absence de réponse.
$ telnet 127.0.0.1 60020
(durée d'exécution 0:02:10.315065)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection timed out
(code de retour 1)
$ nc -t -v 127.0.0.1 60020
(durée d'exécution 0:02:10.256818)
nc: connect to 127.0.0.1 port 60020 (tcp) failed: Connection timed out
(code de retour 1)
$ bash -c exec 3<>/dev/tcp/127.0.0.1/60020
(durée d'exécution 0:02:09.811710)
bash: connect: Connexion terminée par expiration du délai d'attente
bash: /dev/tcp/127.0.0.1/60020: Connexion terminée par expiration du délai d'attente
(code de retour 1)
$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60020
(durée d'exécution 0:02:10.423479)
tcp_open:ztcp:174: connection failed: connexion terminée par expiration du délai d'attente
(code de retour 1)
$ nmap -v -sT -p 60020 127.0.0.1
(durée d'exécution 0:00:00.860462)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:15 CEST
Initiating Ping Scan at 19:15
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:15, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:15
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:15, 0.20s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).
PORT STATE SERVICE
60020/tcp filtered unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds
(code de retour 0)
$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60020 127.0.0.1 -O info
(durée d'exécution 0:00:05.126178)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 *
(code de retour 0)
$ openssl s_client -connect 127.0.0.1:60020
(durée d'exécution 0:02:11.242094)
140029672752256:error:0200206E:system library:connect:Connection timed out:../crypto/bio/b_sock2.c:110:
140029672752256:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=110
(code de retour 1)
$ ssh -p 60020 127.0.0.1
(durée d'exécution 0:02:10.451898)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60020: Connection timed out
(code de retour 255)
$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60020", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
(durée d'exécution 0:02:10.522130)
ERROR in Socket Creation : Connection timed out
(code de retour 110)
$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60020))
(durée d'exécution 0:02:10.415526)
Traceback (most recent call last):
File "<string>", line 1, in <module>
TimeoutError: [Errno 110] Connection timed out
(code de retour 1)
$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60020)
(durée d'exécution 0:02:10.149211)
-e:1:in `initialize': Connection timed out - connect(2) for "127.0.0.1" port 60020 (Errno::ETIMEDOUT)
from -e:1:in `open'
from -e:1:in `<main>'
(code de retour 1)
$ curl -v -s --max-time 60 http://127.0.0.1:60020
(durée d'exécution 0:01:00.105772)
* Expire in 0 ms for 6 (transfer 0x556c2510fc40)
* Expire in 60000 ms for 8 (transfer 0x556c2510fc40)
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x556c2510fc40)
* Connection timed out after 60000 milliseconds
* Closing connection 0
(code de retour 28)
$ wget --timeout=60 --tries=1 http://127.0.0.1:60020
(durée d'exécution 0:01:00.365540)
--2019-06-30 19:27:14-- http://127.0.0.1:60020/
Connexion à 127.0.0.1:60020… échec : Connexion terminée par expiration du délai d'attente.
Abandon.
(code de retour 4)
$ links -dump http://127.0.0.1:60020
(durée d'exécution 0:06:32.165744)
Connection timed out
(code de retour 1)
$ chromium http://127.0.0.1:60020
(Ce site est inaccessible. 127.0.0.1 a mis trop de temps à répondre. ERR_CONNECTION_TIMED_OUT)
$ firefox http://127.0.0.1:60020
(The connection has timed out. The server at 127.0.0.1 is taking too long to respond.
Port TCP en écoute
Au fait, ça donne quoi des connexions TCP réussies ? Dans notre exemple, la connexion est réussie, mais le serveur ne parle pas forcément le bon protocole, et de toute façon il coupe la connexion.
$ telnet 127.0.0.1 60040
(durée d'exécution 0:00:00.109715)
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.Connection closed by foreign host.
(code de retour 1)
$ nc -t -v 127.0.0.1 60040
(durée d'exécution 0:00:00.072833)
Connection to 127.0.0.1 60040 port [tcp/*] succeeded!
(code de retour 0)
$ bash -c exec 3<>/dev/tcp/127.0.0.1/60040
(durée d'exécution 0:00:00.077887)
(code de retour 0)
$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60040
(durée d'exécution 0:00:00.582218)
Session 1 (host 127.0.0.1, port 60040 fd 3) opened OK.
Setting default TCP session 1
(code de retour 0)
$ nmap -v -sT -p 60040 127.0.0.1
(durée d'exécution 0:00:00.575144)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:34 CEST
Initiating Ping Scan at 19:34
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:34, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:34
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 60040/tcp on 127.0.0.1
Completed Connect Scan at 19:34, 0.00s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0022s latency).
PORT STATE SERVICE
60040/tcp open unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
(code de retour 0)
$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60040 127.0.0.1 -O info
(durée d'exécution 0:07:30.000489)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 localhost (127.0.0.1) <syn,ack> 0.097 ms
(code de retour 0)
$ openssl s_client -connect 127.0.0.1:60040
(durée d'exécution 0:00:00.123910)
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---write:errno=104
(code de retour 1)
$ ssh -p 60040 127.0.0.1
(durée d'exécution 0:00:00.210452)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_exchange_identification: Connection closed by remote host
(code de retour 255)
$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60040", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
(durée d'exécution 0:00:01.093543)
(code de retour 0)
$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60040))
(durée d'exécution 0:00:00.156651)
(code de retour 0)
$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60040)
(durée d'exécution 0:00:01.445306)
(code de retour 0)
$ curl -v -s --max-time 60 http://127.0.0.1:60040
(durée d'exécution 0:00:00.182162)
* Expire in 0 ms for 6 (transfer 0x55ebb4398c40)
* Expire in 60000 ms for 8 (transfer 0x55ebb4398c40)
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55ebb4398c40)
* Connected to 127.0.0.1 (127.0.0.1) port 60040 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:60040
> User-Agent: curl/7.64.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
(code de retour 52)
$ wget --timeout=60 --tries=1 http://127.0.0.1:60040
(durée d'exécution 0:00:00.215817)
--2019-06-30 19:42:33-- http://127.0.0.1:60040/
Connexion à 127.0.0.1:60040… connecté.
requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.
Abandon.
(code de retour 4)
$ links -dump http://127.0.0.1:60040
(durée d'exécution 0:00:00.214406)
Error reading from socket
(code de retour 1)
$ chromium http://127.0.0.1:60040
(Ce site est inaccessible. Il se peut que la page Web à l'adresse http://127.0.0.1:60040/ soit temporairement inaccessible ou qu'elle ait été déplacée de façon permanente à une autre adresse Web. ERR_SOCKET_NOT_CONNECTED)
$ firefox http://127.0.0.1:60040
(The connection was reset. The connection to the server was reset while the page was loading.)
Trafic réseau
Jetons un œil au trafic réseau échangé (si le port est fermé, la réponse est un TCP RST ; si le trafic est rejeté, la réponse est un « ICMP port inaccessible » ; si le trafic est poubellisé, le TCP SYN (et les réessais) restent sans réponse ; enfin, si le port est ouvert, la connexion s’établit avec la poignée de main TCP, la fermeture de session pouvant être différente suivant si des données ont été envoyées ou non). Ici, source et destination sont une seule et même machine, mais peu importe.
$ sudo tshark -i lo -f "host 127.0.0.1 and (tcp or icmp)"
Running as user "root" and group "root". This could be dangerous.
tshark: Lua: Error during loading:
[string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled due to running Wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
Capturing on 'Loopback'
(n° paquet, horloge, source -> destination protocole...)
1 0.000000000 127.0.0.1 → 127.0.0.1 TCP 74 39766 → 60001 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10596677 TSecr=0 WS=128
2 0.000016574 127.0.0.1 → 127.0.0.1 TCP 54 60001 → 39766 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
(...)
37 8.190159737 127.0.0.1 → 127.0.0.1 TCP 74 42694 → 60000 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10598724 TSecr=0 WS=128
38 8.190177891 127.0.0.1 → 127.0.0.1 ICMP 102 Destination unreachable (Port unreachable)
39 9.190192177 127.0.0.1 → 127.0.0.1 TCP 74 [TCP Retransmission] 42694 → 60000 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10598975 TSecr=0 WS=128
40 9.190276171 127.0.0.1 → 127.0.0.1 ICMP 102 Destination unreachable (Port unreachable)
(...)
103 28.328151130 127.0.0.1 → 127.0.0.1 TCP 74 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10603759 TSecr=0 WS=128
104 29.326198277 127.0.0.1 → 127.0.0.1 TCP 74 [TCP Retransmission] 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10604009 TSecr=0 WS=128
105 31.330178795 127.0.0.1 → 127.0.0.1 TCP 74 [TCP Retransmission] 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10604510 TSecr=0 WS=128
(...)
207 1683.477081380 127.0.0.1 → 127.0.0.1 TCP 74 45876 → 60040 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=11017546 TSecr=0 WS=128
208 1683.477103411 127.0.0.1 → 127.0.0.1 TCP 74 60040 → 45876 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=11017546 TSecr=11017546 WS=128
209 1683.477118197 127.0.0.1 → 127.0.0.1 TCP 66 45876 → 60040 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11017546 TSecr=11017546
210 1683.477172642 127.0.0.1 → 127.0.0.1 TCP 66 60040 → 45876 [FIN, ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11017546 TSecr=11017546
211 1683.477299723 127.0.0.1 → 127.0.0.1 TCP 66 45876 → 60040 [FIN, ACK] Seq=1 Ack=2 Win=43776 Len=0 TSval=11017546 TSecr=11017546
212 1683.477307741 127.0.0.1 → 127.0.0.1 TCP 66 60040 → 45876 [ACK] Seq=2 Ack=2 Win=43776 Len=0 TSval=11017546 TSecr=11017546
(...)
276 1688.854649280 127.0.0.1 → 127.0.0.1 TCP 66 45900 → 60040 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11018891 TSecr=11018891
277 1688.854689131 127.0.0.1 → 127.0.0.1 TCP 66 60040 → 45900 [FIN, ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11018891 TSecr=11018891
278 1688.854759615 127.0.0.1 → 127.0.0.1 HTTP 145 GET / HTTP/1.1
279 1688.854773879 127.0.0.1 → 127.0.0.1 TCP 54 60040 → 45900 [RST] Seq=2 Win=0 Len=0
Port UDP
Port UDP fermé
Et si l’on teste de l’UDP, lorsque rien n’est en écoute, par exemple, on peut détecter que le port est fermé (globalement le client est notifié de la fermeture).
$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60011
(durée d'exécution 0:00:00.009070)
(code de retour 1)
$ bash -c exec 3<>/dev/udp/127.0.0.1/60011; echo coin >&3; sleep 10
(durée d'exécution 0:00:10.011074)
(code de retour 0)
$ traceroute -U -N 1 -m 1 -q 1 -p 60011 127.0.0.1
(durée d'exécution 0:00:00.030841)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 localhost (127.0.0.1) 0.039 ms
(code de retour 0)
$ sudo nmap -v -sU -p 60011 127.0.0.1
(durée d'exécution 0:00:00.519691)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:42 CEST
Initiating UDP Scan at 19:42
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:42, 0.24s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000090s latency).
PORT STATE SERVICE
60011/udp closed unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds
Raw packets sent: 1 (28B) | Rcvd: 2 (84B)
(code de retour 0)
Port UDP filtré avec rejet
Ou que le trafic est rejeté par un pare‐feu, cela revient plus ou moins au même :
$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60010
(durée d'exécution 0:00:00.027297)
(code de retour 1)
$ bash -c exec 3<>/dev/udp/127.0.0.1/60010; echo coin >&3; sleep 10
(durée d'exécution 0:00:10.010258)
(code de retour 0)
$ traceroute -U -N 1 -m 1 -q 1 -p 60010 127.0.0.1
(durée d'exécution 0:00:00.015655)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 localhost (127.0.0.1) 0.035 ms
(code de retour 0)
$ sudo nmap -v -sU -p 60010 127.0.0.1
(durée d'exécution 0:00:00.392441)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:43 CEST
Initiating UDP Scan at 19:43
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:43, 0.22s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000081s latency).
PORT STATE SERVICE
60010/udp closed unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds
Raw packets sent: 1 (28B) | Rcvd: 2 (84B)
(code de retour 0)
Port UDP filtré avec poubellisation
En revanche, il est devient difficile de différencier le trafic UDP poubellisé du trafic réussi (car le client n’est pas notifié de l’erreur, le protocole UDP n’est pas connecté et ne garantit ni livraison, ni l’ordre d’arrivée, ni la non‐duplication des paquets transmis).
$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60030
(durée d'exécution 0:00:20.026213)
Connection to 127.0.0.1 60030 port [udp/*] succeeded!
(code de retour 0)
$ bash -c exec 3<>/dev/udp/127.0.0.1/60030; echo coin >&3; sleep 10
(durée d'exécution 0:00:10.010664)
(code de retour 0)
$ traceroute -U -N 1 -m 1 -q 1 -p 60030 127.0.0.1
(durée d'exécution 0:00:05.016796)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 *
(code de retour 0)
$ sudo nmap -v -sU -p 60030 127.0.0.1
(durée d'exécution 0:00:02.354541)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:43 CEST
Initiating UDP Scan at 19:43
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:43, 2.04s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up.
PORT STATE SERVICE
60030/udp open|filtered unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.23 seconds
Raw packets sent: 2 (56B) | Rcvd: 2 (56B)
(code de retour 0)
Port UDP en écoute
On retrouve le même résultat sur un test avec effectivement un serveur en écoute :
$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60050
(durée d'exécution 0:00:20.029595)
Connection to 127.0.0.1 60050 port [udp/*] succeeded!
(code de retour 0)
$ bash -c exec 3<>/dev/udp/127.0.0.1/60050; echo coin >&3; sleep 10
(durée d'exécution 0:00:10.015239)
(code de retour 0)
$ traceroute -U -N 1 -m 1 -q 1 -p 60050 127.0.0.1
(durée d'exécution 0:00:05.020411)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
1 *
(code de retour 0)
$ sudo nmap -v -sU -p 60050 127.0.0.1
(durée d'exécution 0:00:02.302030)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:44 CEST
Initiating UDP Scan at 19:44
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:44, 2.03s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up.
PORT STATE SERVICE
60050/udp open|filtered unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.18 seconds
Raw packets sent: 2 (56B) | Rcvd: 2 (56B)
(code de retour 0)
Trafic échangé
Regardons le trafic réseau échangé (un port fermé ou un trafic rejeté génère une réponse « ICMP port inaccessible », et un port ouvert ou un trafic poubellisé ne génère aucune réponse). Ici source et destination sont une seule et même machine, mais peu importe.
$ sudo tshark -i lo -f "host 127.0.0.1 and (udp or icmp)"
Running as user "root" and group "root". This could be dangerous.
tshark: Lua: Error during loading:
[string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled due to running Wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
Capturing on 'Loopback'
(n° paquet, horloge, source -> destination protocole...)
1 0.000000000 127.0.0.1 → 127.0.0.1 UDP 43 58991 → 60011 Len=1
2 0.000018701 127.0.0.1 → 127.0.0.1 ICMP 71 Destination unreachable (Port unreachable)
(...)
9 15.846541876 127.0.0.1 → 127.0.0.1 UDP 43 52810 → 60010 Len=1
10 15.846560153 127.0.0.1 → 127.0.0.1 ICMP 71 Destination unreachable (Port unreachable)
(...)
17 31.086988181 127.0.0.1 → 127.0.0.1 UDP 43 48647 → 60030 Len=1
18 31.086997796 127.0.0.1 → 127.0.0.1 UDP 43 48647 → 60030 Len=1
19 32.087088785 127.0.0.1 → 127.0.0.1 UDP 43 48647 → 60030 Len=1
(...)
34 73.221725214 127.0.0.1 → 127.0.0.1 UDP 43 46294 → 60050 Len=1
35 73.221740517 127.0.0.1 → 127.0.0.1 UDP 43 46294 → 60050 Len=1
36 74.221835792 127.0.0.1 → 127.0.0.1 UDP 43 46294 → 60050 Len=1
TODO : des idées pour la suite
Des idées pour la suite :
- DNS ?
- ip route get to, ping, arp, arping, dns / dig / host, tsocks, lsof / strace, HTTP et proxy, SSH et tunnel ?
- RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency
# Super récapitulatif
Posté par Yves (site web personnel) . Évalué à 7.
Merci pour ce récapitulatif des commandes disponibles. C’est instructif, et ça dépanne quand on est dans un environnement où la commande qu’on connait n’est pas disponible.
# telnet
Posté par Pierre Jarillon (site web personnel) . Évalué à -10.
C'est gentil de commencer par telnet, sauf que telnet n'est plus installé avec ma distribution (Mageia).
Ce n'est pas un oubli, le paquet existe toujours et son titre est netkit-telnet-server - A extremely unsecure telnet server.
Dans la description il est écrit : « Install the telnetd package if you want to support extremely unsecure remote logins to your machine ». Même en étant nul en anglais, on peut comprendre !
telnet est donc une commande à oublier pour des raisons de sécurité, sauf peut-être dans le cas d'un réseau local bien isolé du reste du monde. Il vaut infiniment mieux utiliser ssh, la légère réduction de vitesse due à la cryptographie étant le prix à payer pour la sécurité.
[^] # Re: telnet
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 03 juillet 2019 à 18:18.
Le tcp syn envoyé par telnet n'a pas plus sécurisé que le tcp syn envoyé par ssh (ou firefox). Et le syn ack renvoyé non plus (ni moins) :).
(pour ceux qui ne lisent pas ansible couramment, j'installe les paquets suivant sur une Debian Sid pour le test zsh, netcat-openbsd, telnet, bash, openssl, openssh-client, perl-base, python3-minimal, ruby, curl, wget, links, traceroute)
[^] # Re: telnet
Posté par pasBill pasGates . Évalué à 2.
Je suggérerais netcat plutôt que telnet
[^] # Re: telnet
Posté par seveso . Évalué à 6.
C'est justement le deuxième exemple fourni dans l'article non ?
[^] # Re: telnet
Posté par Laurent GAUTROT . Évalué à 6.
Gentil ou méchant, la commande
telnet
permet d'établir une connexion TCP sur un port arbitraire et pour faire passer n'importe quel type de protocole en texte clair. Le paquet mentionné contient le serveurtelnet
(d'où la mention detelnetd
).[^] # Re: telnet
Posté par steph1978 . Évalué à 10.
Pfiu ça me rappelle des architectes sécurité qui n'ont jamais touché un serveur : "telnet c'est dangereux, ah on va se faire hacker, interdiction de mettre ça sur les serveurs".
"Heu mais telnet nous permet de tester les ouvertures de flux. C'est pas Telnet qui est dangereux, c'est le demon telnet = telnetd, qui est dangereux mille millions de mille sabords !"
De toute façon il vaut mieux utiliser nc.
Et là c'est le retour des architectes sécurité "quoi, nc c'est comme telnet ; ah interdiction !".
Et il y en a qui ont peur des chats noirs ou du chiffre 13…. mais ils ne devraient pas avoir le droit d’édicter des règles.
[^] # Re: telnet
Posté par Yves Bourguignon . Évalué à 9.
Donc en résumé, le serveur telnet (le démon telnetd) aucun intérêt, pas besoin.
Par contre, le client telnet (la commande) très utile pour faire des diagnostics comme montrés ici.
Un autre exemple d'un usage détourné de la commande (on n'essaye pas de se connecter à un serveur telnet), on peut vouloir visualiser le dialogue avec un serveur smtp :
[^] # Re: telnet
Posté par Anonyme . Évalué à 0.
Elle est franchement très peu utile quand tu as
nc
et/ousocat
.[^] # Re: telnet
Posté par freem . Évalué à 5.
Si on omets le fait que tu confondes serveur et client, je suis quasi sûr que tu as un client telnet installé par défaut. Je pense ici à busybox, qui entres autres inclues une implémentation de telnet, ping, netcat, traceroute et bien d'autres.
# à continuer
Posté par Alex G. . Évalué à 3.
Je dirais d'abord ipv6 puis le DNS puis
ip
.C'est bien utile de savoir dépanner.
Perso là où je commence à me perdre c'est quand on est dans les sous réseaux.
# pas compris
Posté par freem . Évalué à 9.
En fait, c'est quoi le message de cette dépêche?
Je ne sais pas pour vous, mais moi je vois surtout un pâté de commandes illisibles et sans explications. Cela dis, ça semble assumé:
En plus, j'aurais tendance, vu le titre et l'intro, à croire que c'est à destination de l'utilisateur d'un réseau, mais rien sur le DNS, rien sur le routeur… Perso, pour savoir ce qui se passe quand «internet est cassé», je bosse pas sur localhost, je commence par ping la cible, ensuite je ping perdu.com, puis je ping 8.8.8.8, puis je ping mon routeur, et en général à ce moment la, je sais ou est le maillon qui merde.
Du coup, je pense que j'ai rien compris. J'en viens même à me demander s'il y a quoique ce soit à comprendre, alors je voudrais bien quelques explications?
[^] # Re: pas compris
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
D'après ce que je comprends, ça répertorie les commandes qui permettent de diagnostiquer pourquoi la connexion est foireuse.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: pas compris
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
C'est toujours le cas devant une langue étrangère si tu ne parles pas la langue en question.
Que te manque-t-il dans les explications qui manquent selon toi ? Quelles sont tes questions ?
Tu peux mettre une autre IPv4 que 127.0.0.1 si tu veux, ça change rien à la question des flux TCP / UDP.
Par ailleurs ping n'aide pas pour les flux TCP / UDP, il envoie des ICMP ECHO_REQUEST.
[^] # Re: pas compris
Posté par Big Pete . Évalué à 4.
Si cela peut changer quelques trucs. Typiquement, si tu as un timeout, peut-être que le paquet SYN s'est perdu en route, peut-être que la route retour n'est pas bonne sur la machine destination et que le SYN-ACK s'est lui perdu en route. Normalement, un firewall que tu es sensé traverser (pas un firewall local) ne fait jamais de rejet avec réponse, mais au cas où il voudrait le faire, il ne peut pas envoyer de RST (parce qu'il ne porte pas l'ip destination ; il peut "spoofé" l'ip destination, mais c'est assez moche). Dans ce cas, il envoi un message icmp (qui peut lui même être filtré ou mal routé), du style "host/net unreachable" ou encore "destination host/net prohibited"
Désolé, je répond un peu en vitesse, du coup, j'ai pas pris le temps de traduite le jargon en français. Enfin, bon sinon, c'est cool d'avoir compilé une liste de commande de test, bien pratique ça.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: pas compris
Posté par Anonyme . Évalué à 5.
Sauf quand il est bien configuré.
iptables -P INPUT DROP
c’est une plaie pour le débug. Je préfère 1000 fois un pare-feu qui me prévient quand je l’ai mal configuré.Perso j’utilise quelque chose dans ce genre :
Et, au besoin, je DROP spécifiquement les « méchants » (genre avec
fail2ban
ousshguard
).[^] # Re: pas compris
Posté par freem . Évalué à 6.
M'enfin, c'est principalement du shell… pas une langue étrangère… en tout cas, pas pour moi.
Si je prend juste le 1er exemple (mais à vue de nez, ils sont tous du même acabit):
Pour l'anecdote, ce pavé est tellement long qu'il semblerait que le select/paste d'X11 a besoin de s'y reprendre à 2 fois.
Pour l'explication de ce qui me plaît pas, perso, je pense que séparer les commandes entres elles aurait rendu la chose nettement plus lisible: ici, on ne peux même pas aisément voir où s'arrête ou se finit une commande.
De plus, scinder aurait permis d'éventuels commentaires sur les options ou la sortie du programme, voire, soyons fous, un commentaire sur la raison de choisir telle ou telle alternative.
Je pense avoir donné quelques indices plus haut dans ce post: pourquoi utiliser telle ou telle alternative, quelles sont les avantages et inconvénients, ce genre de trucs.
Je suis désolé pour ceux qui n'apprécient pas de lire ça, mais même si je reconnais le travail qu'il y a du y avoir pour lister tout ça, je ne suis pas convaincu que la forme lui rende justice, bien au contraire.
Ben si, déjà pas besoin de DNS, qui est un des composants les plus fragiles selon mon vécu propre et me semble bien que localhost est traité de manière spécifique par le noyal, bien que j'aie aucune certitude sur ce point.
Accessoirement, le titre du journal dit bien "internet est cassé", et désolé, mais je ping pas perdu.com sur localhost moi.
[^] # Re: pas compris
Posté par Tonton Th (Mastodon) . Évalué à 2.
Mmmm. je n'en suis pas si sûr. Il me semble qu'il y a des piles IP qui court-circuitent tout ce qu'il y a en dessous quand elles détectent 127/8. Donc ça a un peu d'influence sur la latence, toussa..
[^] # Re: pas compris
Posté par Christophe B. (site web personnel) . Évalué à 5.
Les milles et unes manières de tester la connexion à un port TCP et UDP
honnêtement il faudrait en faire une page bien présentée accessible depuis un smartphone par exemple
car il y en a pour tout les gouts et le couleurs
Beauo boulot merci …
Petite question pour ma culture personnelle :
à part installer le client telnet ou télécharger un emulateur de terminal comme Mobaxterm, quelqu'un connaît des commandes équivalentes sous Windows ?
Merci d'avance
[^] # Re: pas compris
Posté par n.rigaud . Évalué à 2.
Pour info,
sur mon PC pro sous Windows 10 je dispose nativement des commandes suivantes:
- curl
- ssh
- tracert
si je veux aller plus loin, je vais plutôt regarder du côté du powershell, avec par exemple la commande suivante:
- Test-NetConnection
Cette dernière va me permettre de faire aussi bien un ping que tester un port …
Il est très probable que ces possibilités ne soient pas présentes nativement sur des versions plus anciennes de Windows.
[^] # Re: pas compris
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 09 juillet 2019 à 10:22.
d'autres commandes utiles :
[^] # Re: pas compris
Posté par Anonyme . Évalué à 5.
Si ça peut aider certaines personnes :
Ça affiche (quand c’est possible) les numéros d’AS et les infos MPLS. Ça ajoute également une colonne avec le nombre de paquets perdus et ça remplace la colonne écart type par une colonne gigue.
J’aime aussi beaucoup bmon qui affiche le trafic par interface, avec des graphes et des informations assez détaillé :
[^] # Re: pas compris
Posté par Christophe B. (site web personnel) . Évalué à 2.
Merci pour l'info
je vais voir si je retrouve ces commandes sur les versions server
[^] # Re: pas compris
Posté par Anonyme . Évalué à 3.
Quand l’erreur de connexion n’est pas explicite[1], une bonne technique, c’est de prendre le modèle OSI et de remonter couche par couche.
[1] J’entends par là un timeout par exemple, par opposition à un retour HTTP ou un ICMP
port unreachable
.[^] # Re: pas compris
Posté par fredezic . Évalué à 0.
moi généralement je fais l'inverse
je commence par pinger la passerelle par défaut
=> si ca marche pas, je verifie le cablage et l'etat de la passerelle (généralement c'est la box internet)
=> si ca marche, je pinge le 8.8.8.8
==> si ca marche pas je me connecte sur la box, elle ont toute une interface d'admin en http, ca te dit si tu as un probleme avec ton acces internet
==> si ca marche, je teste un ping sur www.google.Fr (ca permet de valider le dns),
===> si ca marche pas, change ton dns sur ta config (tu peux mettre le dns de google par exemple 8.8.8.8)
===> si ca marche, c'est que tu n'as pas de probleme réseau, il faut chercher ailleurs
j'ai déjà eu des problemes avec le dhcp de la box qui ne marchait pas, j'avais du passé en ip fixe. mais c'est plutôt rare
le test des port tcp permet surtout de valider des ouvertures firewall, donc ca se fait surtout dans un cadre pro. je ne vois pas dans quel cas ca peut etre utilisé dans un cadre personnel
[^] # Re: pas compris
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 07 juillet 2019 à 14:26.
« si ca marche, je pinge le 8.8.8.8 » Et si Google vient de décider d'arrêter de répondre aux requêtes ICMP echo, ou bien de limiter le taux de réponse ?
Un test général de connectivité doit se faire vers une machine qu'on contrôle, ou bien vers une machine explicitement prévue pour cela (donc pas Google Public DNS).
[^] # Re: pas compris
Posté par fredezic . Évalué à 0.
Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?)
l'avantage du dns de google c'est que c'est une ip facilement mémorisable et qui répond au ping depuis plusieurs années, donc je sais que google n'est pas apprécié sur ce site, mais ca reste le plus simple quand on veut juste vérifier que son accès internet fonctionne
[^] # Re: pas compris
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
« Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?) » OU BIEN VERS UNE MACHINE PRÉVUE POUR CELA, c'était écrit. Les ancres Atlas, par exemple. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors
[^] # Re: pas compris
Posté par Anonyme . Évalué à 2.
Pour info, les citations en Markdown, ça se fait comme dans dans les courriels :
>
.Peux tu respecter la netiquette s’il te plaît ? :p
[^] # Re: pas compris
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
« si ca marche, je teste un ping sur www.google.Fr » C'est très sommaire comme test :
[^] # Re: pas compris
Posté par fredezic . Évalué à -3.
qui a dit que je voulais une erreur détaillé ?
le but du test est juste de savoir si la résolution dns fonctionne, c'est tout
en plus dig est tres peu connu, même dans le milieu IT, je suis dans l'informatique et je crois etre le seul a l'utiliser dans mon service (je bosse dans une equipe réseau de 15 personnes) nslookup est beaucoup plus connu
en plus ce n'est pas dispo sur windows et c'est beaucoup trop verbeux pour ce qu'on veut y faire
PS: personnelement ca commence a devenir pénible ces ayatola du libre et autre barbu. j'ai du mal a comprendre pourquoi je prends un -1 ou je dis simplement comment je fais moi, alors que toi qui se contente de cracher ton venin prends du +3
oui ce n'est pas très académique, oui si le méchant google décide de couper son ping, ca ne marche plus, mais dans les faits, c'est simple et efficace
franchement ce système de note ca ne donne pas envie de participer
sur ce, ciao et bon dimanche
[^] # Re: pas compris
Posté par Thomas Douillard . Évalué à 2.
(rep au PS) calme toi, son message a juste à l’instant ou je répond un seul vote positif, alors que le tiens à un vote positif et un vote négatif. Faut pas trop tirer de conclusions sur si peu de votes, si ça se trouve le vote négatif de ton post est de quelqu’un qui a cliqué à côté ;)
Sinon les notes sont influencées par l’ancienneté du compte et les votes passé. Tu as peu commenté donc tu es noté par défaut à 0, alors que Stéphane est plus ancien ici et démarre à +2 grâce à l’historique des votes positifs de ses anciens commentaires, cf. https://linuxfr.org/wiki/karma
# internet broke today
Posté par tinodeleste . Évalué à -1. Dernière modification le 04 juillet 2019 à 17:50.
moi qui pensait que ca allait parler de çà :-)
https://arstechnica.com/information-technology/2019/07/facebook-cloudflare-microsoft-and-twitter-suffer-outages/
# « Internet est cassé » ou plutôt : comment diagnostiquer le problème
Posté par Vincent Danjean . Évalué à 2.
J'avoue qu'après le titre et surtout le premier paragraphe (finissant par "identifier le problème"), j'ai été déçu par la fin de l'article. Je n'ai pas le temps de refaire un article complet, mais voici les pistes que j'utilise personnellement quand "internet est cassé".
ip a nm-applet (et /var/log/syslog pour savoir pourquoi la connexion wifi ne s'établit pas le cas échéant)
ip r
test du ping de la gateway (peut ne pas marcher si la gateway les filtre).
Sur un routeur, il faut se méfier des règles de firewall/nat
iptables -L
iptables -L -t nat
ip rule (Pour les cas plus complexes)
Si tout est ok jusque là, alors c'est plutôt un pb réseau que local à la machine.
test du DNS
ping sur 8.8.8.8
ping sur la/les adresses dans /etc/resolv.conf
dig pour vraiment tester le serveur DNS
traceroute/ping pour identifier à quel distance se trouve le pb réseau
telnet (ou les autres commandes de l'article) si une appli particulière ne fonctionne pas (ça peut être firefox) et vérifier les filtrages.
et tout recommencer avec ipv6
ip -6 a
ip -6 r
ip6tables -L
ping6 fe80::XXXX:YYYY%ethZ
...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.